-
Notifications
You must be signed in to change notification settings - Fork 833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Custom Error Formatter #379
Conversation
I think there are a lot of ways you can already accomplish this without any library changes:
|
Well, for sure. But the easier way is to make a function that can adapt the error as you want. That's also the default way for other graphql libraries in other languages (for example javascript). |
Does the JavaScript implementation actually have this feature? If so, reference implementation parity would certainly be a good reason to add this. |
Yes, it does. https://graphql.org/graphql-js/express-graphql/#graphqlhttp I did basically in similar way, changing where nescessary to match go language (since javascript is untyped and dynamic, the formatError function is way more flexible) |
That's not actually in the core JavaScript GraphQL implementation (graphql/graphql-js); it's part of a separate, higher level library (graphql/express-graphql). In the same way that it's not part of the core implementation for JavaScript, my opinion is that it shouldn't be part of the core implementation here either. It would be more comparable to your example if the functionality went into one of the other higher level Go packages such as graphql-go/handler instead. |
That's true. I would implement on handler only if it was possible, but it wasnt. Since it was not exported. That's why I added a customErrorFormater, which is optional. |
Maybe a simpler change that would enable this would be if |
That might not solve the issue, since you have no access to that error before is sent back to the user, and adding original error directly to it might leak private information and / or break the GraphQLError format. |
If you add an unexported If that were added, you could then just add something like this to graphql-go/handler: if customFormatter := h.CustomErrorFormatter; customFormatter != nil {
formatted := make([]gqlerrors.FormattedError, len(result.Errors))
for i, err := result.Errors {
formatted[i] = customFormatter(err.OriginalError())
}
result.Errors = formatted
} |
Hmm, thats true. Let me try to do that. |
Lol, now I need to check those errors. These weren't there XD |
Your change to add an additional field for tracking back the underlying error can also be found in #279 (link). Those CI failures is because many tests use |
Any news about the possibility to custom the error output? |
it may use upgrade handler, src maybe try it! demo: |
Thank you @1046102779 ! |
Any news? |
I added support for a custom error formatter. Sometimes you come with custom
error
objects that might need special parsing to add correctextensions
in a generic way by object type.This implementation doesn't change anything to the flow if no Custom Handler is specified since it uses by default the
FormatError
method. However if you specify, it will run your custom function expecting aFormattedError
to return.Just a quick example:
Then you can use something like:
And everything will work.
I'm also opening a PR in graphql-go/handler since it also benefits in this custom handler. I will put a example there as well.